Feedback 14-03-2025

FISIO FIND - FEEDBACK 14-03-2025

---

ÍNDICE

• 1. RESUMEN DEL FEEDBACK POR GRUPO
  • Primer grupo (Holos):
  • Segundo grupo (Gastrostock):
  • Tercer grupo (Eventbride):
  • Cuarto grupo (BORROO):
  • Quinto grupo (CAMYO):
  • Sexto grupo (FISIO FIND):
• 2. ANÁLISIS DEL FEEDBACK
  • 2.1. TENDENCIAS GENERALES
  • 2.2. COMPARACIÓN DEL FEEDBACK DE NUESTRO GRUPO VS LOS OTROS
  • Discusión para la siguiente clase.
    • PRÓXIMA SEMANA
• 3. CONCLUSIONES Y OBSERVACIONES

---

Ficha del documento

• Nombre del Proyecto: FISIO FIND

• Número de Grupo: Grupo 6

• Entregable: #SPRINT 2

• Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.

• Contribuidores: Alberto Carmona Sicre (autor), Antonio Macías Ferrera (revisor)

• Fecha de Creación: 19/03/2025

• Versión: v1.2

---

Histórico de Modificaciones

Fecha	Versión	Realizada por	Descripción de los cambios
19/03/2025	v1.0	Alberto Carmona Sicre	Primera versión del documento
19/03/2025	v1.1	Alberto Carmona Sicre	Corrección de fecha y sprint
21/03/2025	v1.2	Antonio Macías Ferrera	Corrección de errores ortográficos

1. RESUMEN DEL FEEDBACK POR GRUPO

Primer grupo (Holos):

Feedback alumnos

• Han sabido atraer la atención del público desde el principio. Consigue que empaticemos con la solución.

• Bien identificados los problemas.

• Muy buena la estética en general y costes.

• Se mide la satisfacción dentro del grupo, cosa que los profesores recomendaban.

Feedback recibido (resumen de los comentarios de los profesores)

• Si cuando se pide que se levante la mano nadie la levanta puede quedar mal.

• Muy bueno lo de "tablero scrum para artistas".

• ¿Cómo se rastrean las IAS?

  • Lo hace con los reportes y los administradores.

• Las estimaciones de costes no están muy claras, el CapEx y el OpEx están un poco liados.

• Muy bien el plan B del video. Iba muy lento y lo han adelantado a mano.

• No se ve del todo bien la demo desde el final.

• Métrica del número de commits muy pervertible, por ejemplo, haciendo muchos commits muy pequeños. Número de commits - entrega de issues.

• ¿Cómo solucionan los problemas? Hay que convertir la solución en una métrica.

• No han podido desplegar bien.

• FEEDBACK GENERAL PARA LA CLASE: cuidado con el despliegue por si se acaban los créditos.

Puntos positivos destacados

• Buena estética en general.

• Muy bueno lo de "tablero scrum para artistas".

• Muy bien el plan B del video.

Áreas de mejora sugeridas

• Aclarar las estimaciones de costes.

• Demo mejorable visualmente.

• Sustituir la métrica de número de commits.

Segundo grupo (Gastrostock):

Feedback alumnos:

• El killer opener muy bien conectado con la gente.

• Muy bien explicado lo que hacen y los objetivos.

• Mucha calma a pesar de los errores.

• Está bien que hayan dicho que tienen muchos problemas sin que les de vergüenza, además de detallar cuales han sido y las soluciones.

• Gráficas muy buenas, color rojo y animaciones bien en conjunto.

Feedback recibido (resumen de los comentarios de los profesores)

• El killer opener está razonablemente bien, se pueden usar memes. Falta sacar alguna sonrisa.

• Deberían haber dedicado más tiempo a la retrospectiva, que es lo más importante. Que no esté desplegado el producto es muy malo. Hay que comentar más cuáles han sido los problemas y cómo solucionarlos.

• Ha habido falta de comunicación clara. Y la solución de hacer un grupo grande no es la mejor. Otros compañeros ya han recibido ese feedback anteriormente.

• El cambio a TPV genera dudas, el coste del hardware es dudoso, así como los proveedores si no es página web.

• Explicación PM:

  • Usuarios piloto no quisieron pasar datos reales para la ia. ¿Estaba contemplado en riesgos? Sí, escrepear ¿Se ha empezado a usar?

  • Que sea solo web no funciona en bares porque se debe de usar dos veces. Por eso el TPV.

• Se puede simular la funcionalidad de la IA o pueden crearlos ellos mismos.

• Cuidado con el lenguaje sexista. Solo se han referido a camareros hombres.

• Las animaciones no pueden fallar. En general deben de tener muchos planes B para que si falla algo se pueda solucionar rápidamente, como venir a reuniones de prueba.

• Alabar la sinceridad y honestidad al contar los problemas.

• ¿De qué forma se puede castigar?

  • Si alguien tiene una falta grave, haces toda la funcionalidad. Es algo peligroso.

  • Avisar con tiempo de los strikes.

• El sprint parece que lleva un progreso de más del 50%.

Puntos positivos destacados

• Sinceridad y honestidad.

• El killer opener está razonablemente bien.

Áreas de mejora sugeridas

• Dedicar más tiempo a la retrospectiva.

• Aumentar la comunicación sin formar un grupo grande.

• Funcionalidad de la IA simulable.

• Plan B para las presentaciones.

• Redefinir los castigos y avisos.

Tercer grupo (Eventbride):

Feedback alumnos

• Inicio efectivo original y bueno. Muy buen diseño. Analisis de competidores lo han trabajado. Problemas encontrados muy bien también.

• El documento de IA muy bien. Muy buenos zooms y mejora.

• Al análisis de competidores tiene pinta de haberse echado muchas horas.

• Han tenido plan B para el video, además de traer altavoz propio para que se escuche bien.

• Rendimiento mediante fórmula clara.

• Retrospectiva clara.

• Muy bien la centralización de información por el problema del aislamiento.

• Me gusta la transparencia con la que se muestra el esfuerzo del equipo.

• Muy bien la diapositiva de la IA, miden si se tiene que editar y miden el tiempo ahorrado. Incluso quitan una IA.

Feedback recibido (resumen de los comentarios de los profesores)

• Muy buen killer opener. Se sugiere seguir con la historia.

• Cuando no te acuerdas de algo, puedes beber agua de la botella que está en la mesa. Si está en la mano siempre la atención se va allí.

• Las estimaciones deberían haberse explicado un poco mejor, ha faltado comentar detalles como de dónde sale la gráfica, con qué usuarios de cada tipo, etc.

• Las demos deben de tener datos realistas, para así evitar la falta de profesionalidad.

• Intentar audios más homogéneos: misma velocidad, mismo tono, etc. Sobre todo si hablan distintas personas.

• Se debe comentar lo que va a aparecer en la demo, para así seguir mejor el hilo de esta.

• La fórmula de rendimiento está bien trabajada, pero falta poner los números de cada uno de los miembros, al menos anonimizados. Se recomienda incluso añadir una evolución entre sprints usando gráficas de barras.

• El procedimiento de cómo resolver problemas es muy genérico (en las diapositivas). Está bien poner ejemplos, como el problema de las estimaciones.

• Debe de haber elasticidad en la forma de presentar, tener pensado qué cosas de las que se cuentan sobran, para no perjudicar el ritmo. Se puede volver a transparencias si sobra tiempo.

Puntos positivos destacados

• Killer opener espectacular.

• Fórmula de rendimiento bien trabajada.

Áreas de mejora sugeridas

• Mejor explicación de las estimaciones.

• Audios más homogéneos.

• Comentarlo que va a aparecer en la demo.

• Evitar diapositivas muy genéricas. Incluir ejemplos es recomendable.

• Ensayar más las presentaciones para conseguir una mayor elasticidad.

Cuarto grupo (BORROO):

Feedback alumnos

• Buen desglose de los costes.

• El estudio que han hecho, amortización en base a encuestas, hace que la suposición tenga menos riesgo (estimación de costes).

• Muy buen ritmo.

• Problemas, se han solucionado casi todos. Son transparentes en que hay riesgos que no estaban previstos y en el ritmo de completar las tareas.

• Simple pero claro las alucinaciones de la IA.

• Tabla comparativa, diferencias con los competidores, costes han puesto K para los miles, gráfica de coste muy visual, responsabilidades muy claras.

• Buena estética, cómo se han mostrado los problemas y se han solucionado la mayoría.

Feedback recibido (resumen de los comentarios de los profesores)

• El killer opener no está tan enlazado porque Doraemon tenía muchas cosas que prestar, el nuevo personaje no tiene eso. Habría que mejorarlo.

• El análisis de los costes es muy bueno, pero hay que tener en cuenta cómo evolucionará el avance real de costes.

• Muy buen formato, pero puede ser un problema. No han puesto las medidas para resolver y el cómo miden (métricas).

• Hay que resaltar la característica que están mostrando en la demo.

• La demo parecía en tiempo real, que es algo muy bueno.

• Muy bien haber puesto el incremento de características para el segundo sprint. Lo podrían poner en otro color para que resaltase más.

• ¿Por qué la IA alucina tanto? ¿Por qué sucede eso? No lo saben, pero es raro.

Puntos positivos destacados

• Análisis de costes muy bueno.

• La naturalidad de la demo.

• Inclusión del incremento de características en futuros sprints.

Áreas de mejora sugeridas

• Falta algo de enlace entre el killer opener y la presentación.

• Tener en cuenta la evolución del avance real de los costes.

• No han puesto las medidas para resolver y el cómo miden.

• Resaltar la funcionalidad que se muestra en la demo.

• Realizar análisis de las alucinaciones de la IA.

Quinto grupo (CAMYO):

Feedback alumnos:

• Está bien como han mostrado los problemas, sus soluciones y los resultados.

• Muy bien bots y métricas utilizas para la IA. Muy bien la estética.

Feedback recibido (resumen de los comentarios de los profesores)

• Las métricas muy bien.

• Los íconos en la demo, que indican qué usuario está usando la app en cada momento, son una muy buena idea. Estaría bien que en el killer opener se conectasen los presentadores con dichos iconos, para así enlazar el killer opener con la demo y todo lo demás.

• Debería ser el empleado el que piense en que ojalá haya una app que haga tal y cual, no el empleador, al menos en este caso.

• Revisar CapEx y OpEx, hay que desglosar bien las cosas.

• Hay veces que no hay que traducir ciertas cosas, como code smells -> código que apesta.

• El tema de plantear el problema, la solución, cómo se mide y el avance es superior a todos los grupos. Usar hasta CodiumIA para automatizar métricas de problemas es muy útil. Ayuda a que la obtención de métricas sea lo más barato y automatizado posible.

• Resaltar la gráfica que se cruza de costes y presupuestos.

• La gestión de usuarios pilotos, la gestión del feedback, se asume que todo tiene errores, lo cual no tiene por qué ser así. Hay que generalizar adecuadamente.

Puntos positivos destacados

• Buenas métricas.

• Iconos de usuarios en la demo.

• La gestión de problemas es superior a todos los grupos.

• Gráfica de costes y presupuestos.

Áreas de mejora sugeridas

• Estaría bien que en el killer opener se conectasen los presentadores con los iconos.

• Revisar CapEx y OpEx.

• Cuidado al traducir literalmente.

• Generalizar adecuadamente.

Sexto grupo (FISIO FIND):

Feedback alumnos

• Inicio muy bien explicado.

• Ha gustado mucho el video y cómo manejamos el tema de la seguridad de la verificación por DNI de las personas.

• Gama de colores muy bien usada.

• Hemos desarrollado muy bien el sprint. Parece que se ha planificado muy bien.

• Las redes sociales tienen buena pinta.

• El vídeo está muy bien.

• La gama de colores esta mu bien.

• Hemos metido mas animaciones y le da un buen toque.

• Se han notado las prisas, pero está muy bien preparado. Hay una buena conexión entre diapositivas, buen flujo.

Feedback recibido (resumen de los comentarios de los profesores)

• Han empezado muy rápido. Al final también fue rápido.

• Muy profesional el killer opener.

• "Perder un día entero para ir al fisio", poder ver al usuario en el fisio esperando, en vez de simplemente sentado en el suelo del gym (hablando del video).

• El elevator pitch debería de ser un poquito más lento, hay que hacer un buen énfasis en este.

• Muy bien las gráficas de costes, pero la de pesimista debe de ser menos pesimista.

• Más énfasis en porcentaje de suscripción.

• Muy bien que la demo esté hilada con el killer opener. Se ve razonablemente bien, aunque no se ve el epígrafe de cada párrafo.

• Muy bien el análisis de rendimiento de los compañeros. Extraño mecanismos de quitar puntos. Deben de funcionar en términos de motivación y no de penalización. Funcionar con strikes, 3 strikes.

• Bien planteado el tema de los riesgos. Hay que decir si son nuevos o son ya identificados. También definir si los problemas son ajenos a los riesgos o no.

• Medir el FAQ, si bajan las dudas o si todas se resuelven está funcionando, si se quedan así y no se responden no funciona.

• ¿El feedback de usuarios piloto se ha implementado? Al principio no, porque esta semana no se ha planteado, pero la siguiente ya sí. Recomendable indicar las HU que provengan de usuarios piloto con algún icono,por ejemplo.

Puntos positivos destacados

• Killer opener muy profesional.

• Muy bien las gráficas de costes.

• Muy bien el enlace entre killer opener y demo.

• Muy bien el análisis de rendimiento de los compañeros.

• Bien planteado el tema de los riesgos.

Áreas de mejora sugeridas

• Mayor énfasis en el elevator pitch

• La estimación pesimista debe ser menos pesimista.

• Replantear el mecanismo de puntos, avisos y penalizaciones.

• Información del equipo más resumida.

• Medir el FAQ.

• Destacar las HU provenientes de feedback.

2. ANÁLISIS DEL FEEDBACK

2.1. TENDENCIAS GENERALES

Factores comunes en los comentarios de los profesores

• Importancia del killer opener: En la mayoría de los grupos se ha valorado positivamente la introducción, aunque se han dado sugerencias para mejorar su conexión con el resto de la presentación.

• Demos y presentaciones bien estructuradas: Se ha insistido en que la demo debe estar bien enlazada con la presentación y que debe haber un plan B en caso de fallos técnicos.

• Uso de métricas: Se ha valorado mucho la inclusión de métricas para evaluar el progreso y la efectividad de las soluciones propuestas.

• Claridad en la comunicación: Se ha recomendado que las explicaciones sean claras y bien organizadas, evitando información excesivamente genérica.

• Estimaciones de costes: La mayoría de los grupos han recibido observaciones sobre la necesidad de mejorar la presentación y desglose de los costes.

• Uso de IA y su justificación: Se han señalado dudas sobre cómo funciona la IA en algunos casos y cómo se podría mejorar su implementación.

• Lenguaje y comunicación inclusiva: En algunos casos, se ha sugerido mejorar la inclusión en la comunicación, evitando sesgos de género en las explicaciones.

Puntos de fortaleza general en los equipos

• Buena preparación de las presentaciones: En general, los equipos han demostrado haber trabajado en la presentación, con materiales bien organizados y estructurados.

• Uso de gráficos y métricas: Varios equipos han incorporado gráficos bien diseñados para respaldar su análisis, lo cual ha sido valorado positivamente.

• Capacidad de adaptación: Algunos equipos han demostrado una buena capacidad de reacción ante problemas imprevistos, como dificultades técnicas en los videos o demos.

• Sinceridad y transparencia: Se ha valorado que los equipos admitan sus errores y expliquen cómo han trabajado para solucionarlos.

Áreas de mejora recurrentes

• Tiempo dedicado a la retrospectiva: Se ha mencionado en varios grupos que no se ha dedicado suficiente tiempo a la retrospectiva del proyecto, algo clave para evaluar el aprendizaje.

• Claridad en las estimaciones de costes: Muchos equipos han recibido comentarios sobre la falta de precisión en los cálculos de costes y su desglose.

• Mejora en la presentación de datos y métricas: Aunque hay un buen uso de métricas, se ha sugerido mejorar la forma de presentarlas para que sean más claras y útiles.

• Ritmo y fluidez de la presentación: Algunos equipos han recibido recomendaciones sobre la velocidad de su discurso y la necesidad de estructurar mejor su presentación.

• Mayor planificación para mitigar errores: Se ha enfatizado la importancia de tener planes B para evitar problemas en demos, animaciones y presentaciones en general.

2.2. COMPARACIÓN DEL FEEDBACK DE NUESTRO GRUPO VS LOS OTROS

¿Qué estamos haciendo bien en comparación con otros?

• Killer opener muy profesional: Nuestro grupo ha recibido elogios por la introducción, destacando su calidad profesional y su capacidad para captar la atención.

• Buen uso de gráficos de costes: Aunque se sugiere mejorar la estimación pesimista, en general, los gráficos han sido bien valorados, a diferencia de otros grupos que han recibido críticas más severas sobre la claridad de los costes.

• Buena conexión entre el killer opener y la demo: Algo que ha sido una recomendación para otros grupos (como CAMYO y BORROO) se ha valorado positivamente en nuestro caso.

• Buen análisis de rendimiento del equipo: Se ha destacado que el análisis del rendimiento ha sido sólido y detallado, algo que no ha sido tan mencionado en otros grupos.

• Enfoque claro en la planificación de riesgos: Nuestro equipo ha sido reconocido por plantear bien los riesgos y diferenciarlos de los problemas, lo cual ha sido un punto débil en otros grupos.

¿Qué aspectos debemos mejorar respecto a los demás?

• Mayor énfasis en el elevator pitch: Aunque nuestro killer opener ha sido profesional, se sugiere hacer un poco más lento el elevator pitch para enfatizar mejor los puntos clave.

• Ajustar la estimación pesimista de los costes: Aunque hemos recibido elogios por los gráficos de costes, se ha señalado que la estimación pesimista es demasiado pesimista y debe ser ajustada.

• Replantear el sistema de puntos y penalizaciones: Se ha sugerido que los mecanismos de penalización no sean punitivos, sino motivacionales. Otros equipos han tenido enfoques diferentes en este aspecto.

• Mejorar la medición del impacto del FAQ: Se ha sugerido medir mejor la efectividad del FAQ para comprobar si realmente está resolviendo dudas o si es necesario hacer ajustes.

• Destacar mejor las HU provenientes del feedback de usuarios piloto: Se nos ha recomendado indicar con algún icono qué HU vienen de los usuarios piloto.

Discusión para la siguiente clase.

• De cara a la KB y a los documentos md: se pueden poner enlaces, así que usémoslos. Por ejemplo, esfuerzo de los compañeros y se mencionan las horas de cada uno, pues un enlace a otro documento donde estén esas horas. En el docusaurus, el repo da info sobre las personas que han contribuido, pues tener un README con aquellos que lo hayan hecho.

• Información de licencias, de SLA con usuarios piloto, se pueden ir poniendo.

• Respecto a la KB, debería haber un protocolo de aportaciones y un buscador.

• Queremos evidencias de lo que ha hecho cada uno.

• Recomendable el uso de changelogs de conventional commits para automatizar cosas.

• Todo lo que se pueda automatizar y de métricas gratis, bienvenido es.

• Es interesante ver la evolución en esfuerzo de tiempo a lo largo de la asignatura.

• Destacar el empleado de la semana, o algo así. Que en base al rendimiento se pongan rankings.

• El feedback positivo (métricas bien medidas, las soluciones detalladas de los problemas y la evolución de estos) debe ser tenido en cuenta por los grupos.

PRÓXIMA SEMANA

• 15 min de duración.

• Introducción inicial.

• Refinamiento del negocio

  • Killer opener de 1 minuto como máximo.

  • Elevator pitch directo.

  • Que el killer opener enlace con el elevator pitch. Este último puede incluso sobrar.

  • Análisis de competidores.

  • Pensar en el guión, un story board, de un anuncio. Anuncio de usuarios, anuncio de clientes y anuncio de inversores (totalmente distinto a los otros 2, dar un resumen y DATOS).

  • Ir pensando en implicaciones legales: GDPR, licencias, etc. Pensar en cómo se implementarían.

• TCO

  • CapEx es todo aquello que capitalizas, cosa que compra tu empresa y que puedes incluso vender a posteriori. Servidores (no en la nube, que eso se “alquila”),

  • Situación actual frente a la prevista

  • Estimaciones pesimistas, esperadas y optimistas

• Demo de la mitad del sprint 2: el incremento de las características de demos anteriores es interesante. Usar datos realistas.

• La demo debe tener pago real.

• Retrospectiva de mitad del sprint 2.

• Gestión de usuarios piloto.

• Planificación reestimando el sprint 2 si a mitad vamos mal. Justificar recortes si son necesarios y centrarse en funcionalidades core.

• Usuario de IAs.

• Diapositiva final.

3. CONCLUSIONES Y OBSERVACIONES

• Nuestra presentación ha sido bien valorada en cuanto a estructura y claridad, pero debemos mejorar el ritmo, especialmente en el elevator pitch, haciéndolo más pausado para enfatizar los puntos clave.

• El killer opener ha sido considerado profesional y bien ejecutado, pero podemos mejorar la conexión entre la introducción y el problema que queremos resolver para que el mensaje sea aún más impactante.

• Nuestro uso de gráficos y métricas ha sido destacado, pero se nos ha sugerido hacer la estimación pesimista menos extrema, ajustando los valores para reflejar mejor la realidad del proyecto.

• El sistema de puntos y penalizaciones necesita ser replanteado. En lugar de enfocarnos en sanciones, podríamos orientarlo hacia un mecanismo de motivación para mejorar el compromiso del equipo sin generar un impacto negativo en la moral.

• La gestión del feedback de los usuarios piloto ha sido reconocida como un aspecto importante, pero se nos recomienda hacer más visible qué cambios han surgido a partir de ese feedback. Podemos incorporar iconos o indicadores en las HU para resaltar su origen.

• Se nos ha valorado por una buena conexión entre el killer opener y la demo, lo cual ha sido una debilidad en otros grupos. Debemos seguir reforzando este punto y asegurarnos de que cada parte de la presentación fluya de manera coherente.

• La demo ha sido bien recibida, pero se ha señalado la importancia de medir la efectividad del FAQ. Implementar métricas que evalúen si realmente está resolviendo dudas nos permitirá validar su impacto en la experiencia del usuario.

• Aunque hemos manejado bien los riesgos y problemas, debemos dejar más claro si los problemas son ajenos a los riesgos previstos o si han surgido de manera inesperada. Esto nos permitirá demostrar un mejor control del proyecto y una capacidad de respuesta más efectiva.

---

Aprobado por:
Scrum Master: Antonio Macías Ferrera
Secretario: Alberto Carmona Sicre